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(57) ABSTRACT 

In a label switched path (LSP) including lab el sw itching 
nodes, some of which process a Time To Live (Tl'L) value 
of a generic label header and others of which that do not 
process the TTL value, an adequate hop-count information 
regarding the LSP is reported from node to node by using a 
label distribution protocol. A node, which has received a 
message including a hop-count of the LSP from an upstream 
node or a downstream node, determines whether or not the 
node itself is to update the TTL value in a packet if received 
through the LSP The node then transmits a message indi- 
cating that the hop-count is one or a message including the 
incremented hop-count, in accordance with this 
determination, to the downstream node or the upstream 
node. Thus, upon transferring packets on the LSP, the nodes 
forming the LSP that process the TTL value can appropri- 
ately decrement the TTL value of the packet. 

15 Claims, 15 Drawing Sheets 
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METHOD OF MANAGING HOP-COUNT IN 
LABEL SWITCHING NETWORK AND NODE 
APPARATUS 



BACKGROUND ART 

The present invention generally relates to a hop-count 
management method and to a node apparatus using this 
method. 

In a node apparatus performing packet communications 
by using, for example, Internet Protocol (IP), control infor- 
mation for assigning specific labels to specific packet 
streams can be exchanged between nodes. Each node then, 
stores input labels (and input interfaces) and output labels 15 
(and output interfaces) assigned to the individual streams, 
and performs a packet transfer operation (switching 
operation) in accordance with the relationship between the 
stored input and output labels. This scheme is referred to as 
a "label switching technique". 

Generally, the lengths of the labels are fixed, and faster 
processing is achieved and more flexible path control is 
enabled by employing the above-described label switching 
packet transfer operation than by utilizing a conventional 



20 



value filled in the generic label header field is used as 
switching information. 

In the generic label header, not only a label field used as 
the switching information, but also a Time-To-Live (TTL) 
field for checking the number of nodes through which a 
packet passes (hereinafter sometimes referred to as a "hop- 
count") and a Class of Service (CoS) field for indicating the 
priority of performing transfer operation are defined. The 
TTL field and the CoS field are also defined in a conven- 
tional IP packet header. If each node (not only the ingress 
node and the egress node, but also an intermediate node) 
decrements the TIL value in the generic label header 
one-by-one upon transferring a packet by label switching, it 
is possible to discard the packet which have passed through 
a number of nodes greater than a predetermined number of 
nodes due to a reason, such as circling in the transfer path 
(routing loop). 

In contrast, if the aforementioned first technique, i.e., a 
known datalink switching technique, is used for implement- 
ing label switching, a Virtual Path Identifier/Virtual Channel 
Identifier (VPI/VCI) field of an ATM cell header or a Data 
link Circuit Identifier (DLCT) field of a frame relay header 
may be used as a label field. 

In this case, a standardized ATM cell header format or 



packet transfer operation performed b y analyzing packet 25 ^ je j a header format is used, but the TTL field and the 



header information (destination IP address prefix, etc.). 

The path through which packet streams are label-switched 
is referred to as a "label switched path (LSP)". A node, 
which is located at the ingress of the LSP for transferring a 
packet stream, is referred to as an "ingress node", and 
performs packet transfer after analyzing an IP packet which 
belongs to the packet stream and attaching a label to the 
packet. A node, which is located at the egress of the LSP for 
transferring the packet stream, is referred to as an "egress 
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CoS field discussed previously are not defined for these 
header formats. Accordingly, once a packet (cell) is input 
into an LSP formed by the ATM virtual connection (VC), it 
may not be discarded and circles indefinitely in the LSP due 
to, for example, routing loop. 

As one of the measures to overcome the above-described 
drawback, the following method has been proposed By 
using a Label Distribution Protocol (LDP) for establishing, 



transiemng tne pacjeet siream, is reierrea 10 as an egress mainlaining) aod releasing an LSP, the number of nodes 

node^ and performs packet fr^^^ 35 through which a packet passes (the hop-count) in each LSP 

from the received packet A node, which is placed between ^ 
the ingress node and the egress node in the LSP so as to 



connect these nodes, is referred to as an 'intermediate 
node", and performs packet transfer in accordance with the 
relationship between the input and output labels. 

A stream to be transferred in a certain LSP may be various 
packets, such as a packet provided with a specific destination 
IP address, a packet provided with a specific destination IP 
address prefix (network address), and a packet passing 
through a specific egress node belonging to a certain 
domain. 

LSPs may include at least point-to-point LSPs for unicast 
streams (one ingress node and one egress node are 
provided), and point-to-multipoint LSPs (one ingress node 
and a plurality of egress nodes are provided, and the LSP is 
branched off at an intermediate node into at least two 
portions) for multicast streams. Additionally, multipoint-to- 
point LSPs (a plurality of ingress nodes and a single egress 
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through which a packet passes (the hop-count) i 
from an ingress node to an egress node is stored in the 
ingress node or in the egress node. Then, when a packet is 
actually transferred, the TTL value of the IP packet header 
is decremented by the hop-count stored in the ingress node 
or the egress node. 

In this method, the ingress node transmits a "label request 
message" for requesting an assignment of a label to a 
specific packet stream defined by, for example, a destination 
45 network prefix. Then the downstream node receives the label 
request message and further transmits it to its neighboring 
node toward the egress node. In this manner, the label 
request message is forwarded to the egress node, and the 
egress node sends back a "label mapping message" for 
assigning the label to the specific packet stream. 
Alternatively, the egress node may voluntarily transmit a 
label mapping message to the upstream node, even if it does 
not receive any label request message. Then the upstream 
node receives the label mapping message and further trans- 
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node are provided) may be defined if a stream merge 55 nuts it to its neighboring node toward the ingress node, 
function of relating a plurality of input labels to a single The label mapping message transmitted from the egress 

output label is provided in an intermediate node. nodc mcludcs not only mc Ube i va i uc to ^ informed to the 

To specifically implement the above-described label upstream node's, but also the hop-count representing a value 

switching, a header defined in the known datalink switching 0 f one. When a node receives the label mapping message 

technique, such as an asynchronous transfer mode (AIM) go from its neighboring downstream node, the node transmits 

and a frame relay, may be used. Alternatively, a label header the label mapping message to its neighboring upstream node 

newly defined specifically for label switching may be used. after incrementing the hop-count value by one. Ultimately, 

In the second technique, a label header field (hereinafter the ingress node that has transmitted the label request 

referred to as a "generic label header") is inserted between message receives the label mapping message and stores the 

a point-to-point protocol link (PPP link) frame header and an 65 hop-count value indicated in the label mapping message, 

IP header or between a logical link control (LLC) header of which represents the number of nodes between the ingress 

a local area network (LAN) and an IP header, and a label node and the egress node. 
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Then, when the ingress node receives a packet belonging 
to a packet stream corresponding to the above-described 
label, it decrements the TTL value of the packet header by 
the stored hop-count value and checks whether the decre- 
mented TTL value has reached zero before transmitting the 
packet. If the TTL value has reached zero, the packet may be 
discarded at the ingress node. 

The aforementioned method, where the number of hops in 
the LSP from the ingress node to the egress node is informed 
to the ingress node by the label mapping messages and the 
ingress node decrements the TTL value of a packet to be 
transmitted through the LSP by the informed hop-count 
value, is effective only when all the intermediate nodes 
located on an LSP are unable to check and update the TTL 
value in a packet transferred. That is, it is effective only in 
a system where all the nodes forming the LSP use the same 
known datalink switching technique, such as ATM or frame 
relay. 

Considering an actual label switching network* both ATM 
and frame relay may be employed, or both ATM and a 
Synchronous Optical Network (SONET)-based point-to- 
point link may be used, in a single network. However, the 
control mechanism previously discussed above has been 
proposed, assuming that one of ATM and frame relay is 
solely used in the label switching network and that all the 
intermediate nodes located on an LSP are unable to perform 
TTL processing. 

Consequently, the proposed control mechanism cannot 
deal with a case where two or more different types of 
network segments arc provided in one LSP, especially where 
one type of the network segments includes an intermediate 
node which is able to check and update the TTL field of the 
generic label header and another type of the network seg- 
ments includes an intermediate node which is unable to 
perform TTL processing. 

DISCLOSURE OF THE INVENTION 

It is therefore an object of the present invention to provide 
a hop-count management mechanism for enabling each node 
of the LSP, that transfers a packet by using the label 
switching technique to appropriately decrement the TTL 
value, especially in a case where one LSP is established 
through both a node that can process a TTL value of an IP 
header or a generic label header and a node that cannot 
process the TTL value, so that an adequate TTL value, which 
realizes an interoperablity with a conventional hop-by-hop 
transfer technique, can be provided in the IP header of the 
packet output from the egress node of the LSP. 

According to one aspect of the present invention, there is 
provided a method of managing a hop-count value of a label 
switched path (LSP) which is configured by nodes that 
perform a label switching operation on an input packet by 
referring to a correlation between input labels and output 
labels assigned to a packet stream corresponding to the input 
packet. In this method, a node, which has received from one 
of an upstream node and a downstream node a message (for 
example, the label request message or the label mapping 
message) including a hop-count of the LSP, determines 
whether or not the node itself is going to update, upon 
performing the label switching operation on a packet 
received, information (for example, the TTL value) included 
in the packet concerning the number of nodes through which 
the packet passes. 

If the node determines that the information is not to be 
updated in this node, the node increments the hop-count in 
the received message by a prescribed value (for example, by 
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one), and then transfers the message to other of the upstream 
node and the downstream node. This message including the 
hop-count is preferably received from the downstream node 
and transferred to the upstream node in a case of establishing 

5 a unicast or stream-merge LSP, and is preferably received 
from the upstream node and transferred to the downstream 
node in a case of establishing a multicast LSP. If the node 
determines that the information is to be updated in this node, 
the node transmits a message indicating that the node itself 

10 is going to update the information (for example, a message 
including a value of one as the hop-count or a message not 
including the hop-count) to the other of the upstream node 
and the downstream node. 
When the node that determines to update the information 

15 by itself receives a packet through the LSP, the node updates 
the information in the received packet based on the hop- 
count which has been reported from the one of the upstream 
node and the downstream node and is stored in the node (for 
example, the node decrements the TTL value in the packet 

20 by a value of the hop-count). In other words, if the one of the 
upstream node and the downstream node does not have a 
function of updating the information, the node is supposed 
to have received the message including the hop-count incre- 
mented (for example, two or greater), and thus the node 

25 updates the information based on this incremented hop- 
count. 

If the one of the upstream node and the downstream node 
has a function of updating the information, the node updates 
the information in the received packet by a predetermined 
30 value (for example, decrements the TTL value by one). In 
practice, the predetermined value may also be stored in the 
node as the hop-count that is referred to upon updating the 
information. 

35 According to the principle of the above-described present 
invention, the upstream node that processes the TTL value 
can decrement it in advance by the number of hops from that 
node to a downstream node some hops ahead that subse- 
quently processes the TTL value, for example, in a unicast 

^ or stream-merge LSP passing through both a node that is 
able to process the TTL value of the generic label header and 
a node that is unable to process the TTL value. Alternatively, 
the downstream node that processes the TTL value can 
decrement it later by the number of hops from an upstream 

45 node some hops before that previously processes the TTL 
value to that node, for example, in a multicast LSP passing 
through the above different types of nodes. As a whole, an 
adequate TTL value of an IP header, which is equivalent to 
that will be obtained by a bop-by-hop transfer technique, can 

50 be provided for an IP packet output from the egress node of 
the LSP to a network operated by the hop-by-hop transfer 
technique. 

In the aforementioned method, a node may determine that 
it is to update the information, when any one of the input 

55 label and the output label is set in the same header field (for 
example, the generic label header field) as the header field 
in which the information is contained. 

A node may determine that it is not to update the 
information, when both the input label and the output label 

60 are set in a header field (for example, a layer-2 header field) 
different from a header field in which the information is 
contained. Alternatively, a node may determine that it is to 
update the information, when neither of the input label nor 
the output label is set in the same header field as the header 

65 field in which the information is contained, but when the 
type of input label and the type of output label are different 
(for example, an ATM header and a frame relay header). 
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According to another aspect of the present invention, FIG. 14 is a block diagram illustrating an exemplary 

there is provided a node apparatus for operating the above- configuration of a core node, which serves as an interme- 

described method. diate node of an LSP; 

According to yet another aspect of the present invention, FIGS. 15(a) and 15(b) illustrate an exemplary control 
there is provided a computer usable medium having com- 5 procedure including TTL processing employed in a case 
puter readable program code means embodied therein for a where multicast communications are performed in a network 
computer functioning as the above node apparatus. including segments that perform switching by using a label 
Other features and advantages of the present invention value of the generic label header and segments that perform 
will become apparent from the following description taken switching by using a label value of the layer-2 header; and 
in conjunction with the accompanying drawings. 10 FIGS. 16(a) and 16(b) illustrate another exemplary con- 
Both the foregoing general description and the following trol procedure including TTL processing employed in a case 
detailed description provide examples consistent with this where multicast communications are performed in a network 
invention and explain how to make and use systems, including segments that perform switching by using a label 
methods, and articles of manufacture consistent with the value of the generic label header and segments that perform 
invention. These descriptions do not restrict the claimed 15 switching by using a label value of the layer-2 header. 



invention. 



DESCRIPTION OF THE PREFERRED 



BRIEF DESCRIPTION OF THE DRAWINGS EMBODIMENTS 
FIG. 1 illustrates an example of the format of a generic In a network, both ATM and a point-to-point link may be 

label header; 20 employed. For example, ATM may be used from an ingress 
FIGS. 2(a), 2(b) and 2(c) illustrate an exemplary control node to 411 intermediate node in an LSP, and a point-to-point 
procedure in a case where packet transfer on an LSP is ma Y »* from me intermediate node to an egress 

performed based on the generic label header, and where or conversely, a point-to-point link may be employed 

intermediate nodes execute TTL processing; „ from «" Egress node to an intermediate node in an LSP, and 

FIGS. 3(*), 3(*) and 3(c) illustrate an exemplary control * *™ "J * *™ * e ^ rmediat " ^ 

procedure in a case where packet transfer on an LSP is casc ' ^ ° f decrementing the Til. 

performed based on a layer-2 header, and where intermedin ^ f ^ m ^ no * mc n ? m * r ° f !?^ m 
, j t ttt the ingress to the egress node, it is preferable to identify in 

i , one lip a segmenf which is capable of decrementing the 

FIGS. Ma) MP, 4(c) and M& illustrate an example of a 30 ^ value and a m ^ ^ ^ ble of decrement . 
control procedure mduding TTL processing employed in a m tne ^ val ^ mat each node located m me lsp 
case where an LSP mcludes segments that perform switch- ^ e h unt in f ormation by uiih2ing a Label 

mg by using a label value of the generic label header and Dist ribution Protocol (LDP) so that other nodes can manage 
segments that perform switching by using a label value of ±c hop-count information and appropriately decrement the 

the layer-2 header; 35 ^ttL value. A specific hop-count management method is 

FIGS. 5(a), 5(b), 5(c) and 5(d) illustrate another example described below with reference to the drawings, 
of a control procedure induding TTL processing employed ^G. 1 illustrates an example of the format of a generic 
in a case where an LSP includes segments that perform kbel header A fouf b ric ^ header defined for 

switching by using a label value of the generic label header label ^h^g mcludes a label field 101, a Class of Service 

and segments that perform switching by using a label value 40 ic^^^^^^^^f^i^^^j^^ 
of the layer-2 header, Uvc field m 

FIGS. 6(a), 6(b) 6(c) and 6(d) iUustrate yet another The ^ label header ^ inserled between a layer-3 
example of a control procedure including TTL processing header (for e { ^ ip and a j 2 header (for 

employed m a case where an LSP includes ^segments that e ^ a PPP header , a LAN header such as an 

performswitchmgbyusm^ « 3/Ethcrnct headcr> a ^ mc rclay headcr , ctc .). If 

header and segmente that perform switching by using a label ^ laycf 2 is based on ATM, the generic label header is first 
value of the layer-2 header; addcd to ^ laycr ^ hcadcr> wMch ^ thcn providcd ^ m 

FIG. 7 illustrates an example of a stream information adaptation layer (AAL) trailer. The resulting packet is 

table; ^ then formed into ATM cells, and then, cell headers are 

FIG. 8 illustrates an example of a label information table; provided. An ATM cell is a kind of a frame like an Ethernet 

FIG. 9 is a flowchart illustrating an exemplary operation frame, etc. 
performed upon receiving a label mapping message from a a description is given below of a label switching opera- 
downstream node; tion performed by the ingress node, the intermediate node, 

FIG. 10 is a flowchart illustrating an exemplary operation 5S and the egress node, a method for processing the TTL value 
of a determination as to whether the node that has received of the generic label header by some nodes, and a label 
the label mapping message is going to execute TTL pro- distribution protocol procedure for enabling such TTL 
ccssing on the generic label header, processing, in cases of various types of layer-2 media 

FIG. 11 is a flowchart illustrating an exemplary operation (datalink). 

performed upon receiving a label request message from an 60 An example of the configuration of an edge node, which 
upstream node; serves as the ingress node or the egress node of an LSP in 

FIG. 12 is a flowchart illustrating another exemplary this embodiment, is shown in FIG. 13, and a core node, 
operation performed upon receiving a label mapping mes- which serves as an intermediate node of the LSP in this 
sage (or updating message) from a downstream node; embodiment, is shown in FIG. 14. 

FIG. 13 is a block diagram illustrating an exemplary 65 In an edge node 1300 of FIG. 13, which serves as the 
configuration of an edge node, which serves as an ingress ingress node, unlabeled frames are received by an unlabeled 
node or an egress node of an LSP; frame transmitter/receiver 1308, and the layer-2 headers, for 
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example, Ethernet headers, of the unlabeled frames are then are determined in an LSP-status manager 1401. The contents 

processed in a layer-2 header processor 1306. By referring of the LSP-control processing include control messages to 

to a stream information table 1301 based on the layer-3 be sent to neighboring nodes, and information required in 

information and/or upper- layer information of the packets this core node for label switching (label value to be provided 

assembled from the frames, a packet processor 1304 clas- 5 anc j jjL value to be decremented, etc.). After processing the 

sifies the packets into specific streams, and obtains contents control message in the above manner, at least a part of 

of the processing to be executed on each stream. The resulting information is stored in the label information table 

contents of the processing includes an output interface, the 1403 ^ be discussed later, 

type and value of label (of the generic label Reader oi ^the Amemod for ^ decrementiDg the revalue 

ayer-2 header) to bet provided when ^ 1Q ^ various DCtW ork environments is discusL below, 

to the stream are output as frames, CoS information, and the , J7 T AVT 

TTL value of the generic label header. In accordance with Io f a fi ? * e ™ m P le > on Jy PPP links and/or LAN media are 

the contents obtained by the packet processor 1304, employed as the layer-2 media of an LSP. In this network 

adequate headers are provided for the stream in a generic environment^ TTL processing executed when packet transfer 

label header processor 1305 and in the layer-2 header ^performed based on the generic label header shown m 

processor 1306, and a resulting labeled frame is then trans- FIG. 1 is as follows. 

mitted from a labeled-frame transmitter/receiver 1307 of a Referring to FIGS. 2(a)-2(c), an ingress node 201 of the 

specified output interface. LSP first checks a stream information table 701 shown in 

If the edge node 1300 is used as the egress node, a labeled ™ G - 7 Corresponding to the stream information table 1301 

frame received by the labeled-frame transmitter/receiver 20 shownmnG.13)byusmg,^^^ 

1307 is unlabeled in the reverse order to that employed for example, destination layer-3 address, source laycr-3 address 

labeling the packets in the ingress node, and the unlabeled and so on) obtained by referring to the header of a received 

frame is transmitted from the unlabeled frame transmitter/ kyer-3 packet, and determines the output interface and the 

receiver 1308 of a specified output interface. **tofi of a generic label header (label value, CoS value 

Packets transmitted and received by the edge node 1300 M ^^^^^S^^^^^T^^ 

contain not only packets that are processed in the above- ^^^^^^^^i^tl^f^ 

described way for label switching, but also control messages ^ **? me laver " 2 frame ^ m tne deter " 

used for establishing and releasing LSPs. The control mes- out P ut mterface - 

sages are analyzed in a control message processor 1303, and In mis me value (kbel_ttl) of the generic label 

contents of the LSP-control processing to be executed is 30 header to be attached to the frame to be output is obtained 

determined in an LSP-status manager 1302. The contents of by decrementing the TTL value (ip_ttl) of the layer-3 header 

the LSP-control processing includes control messages to be of me received packet by one. 

sent to neighboring nodes, and information required in this Upon receiving the layer-2 frame, each of label switching 

edge node for label switching (label value to be provided and routers 202-206 processes the layer-2 header and then 

TTL value to be decremented, etc.). After processing the 35 checks a label information table 801 illustrated in FIG. 8 

control message in the above manner, at least a part of (corresponding to the label information table 1403 illus- 

resulting information is stored in the stream information trated in FIG. 14) by using, as a key, the label field of the 

table 1301, which will be discussed later. generic label header (and the CoS field if necessary). As a 

In a core node 1400 of FIG. 14, labeled frames are result, each of the label switching routers 202-206 dcter- 
received by a labeled-frame transmitter^eceiver 1406. If a 40 out P ut ™terf«e and the label field value to be 
label value for frame switching is contained in the layer-2 provided, and also decrements the TTL field value of the 
header (for example, if the datalink used in receiving the generic label header by one. Then, each of the label switch- 
frames is ATM or frame relay), the content of the layer-2 kg routers 202-206 overwrites the generic label header of 
header is referred to as a key to search a label information the received frame by these new label value and TTL value, 
table 1403 by a layer-2 header processor 1405. Otherwise 45 attaches a new layer-2 header to the frame, and then outputs 
(for example, if the datalink used in receiving the frames is mis l aver - 2 ^me from the determined output mterface. 
LAN or PPP), the content of a generic label header obtained Ultimately, after receiving the layer-2 frame and process- 
after executing normal layer-2 processing is used as a key to ing the header of the layer-2 frame, an egress node 207 
search the label information table 1403 by a generic label checks the label field of the generic label header, and 
header processor 1404. Subsequently, a switch 1407 per- 50 identifies the type of upper-layer protocol and confirms that 
forms frame switching in accordance with the result the egress node 207 is a terminating point of the LSP. The 
obtained by searching the label information table 1403, and egress node 207 then removes the generic label header and 
the previous layer-2 header or generic label header is outputs the resulting packet from a determined interface 
replaced by a new layer-2 header or generic label header in after performing layer-3 processing. In this case, the TTL 
accordance with the result obtained by searching the label 55 value of lne layer-3 header to be attached to the packet to be 
information table 1403. If the core node 1400 is an inter- output from the LSP is obtained by decrementing the TTL 
mediate node that processes generic label headers, the result value of the generic label header of the received frame by 

obtained by searching the label information table 1403 one. 

includes also the TTL value to be decremented, and the TTL According to the aforementioned procedure, the TTL 

value in the generic label header is overwritten. Finally, a 60 value (n-7), which is the same as the value that is supposed 

switched frame is transmitted from the labeled-frame to be obtained by a conventional hop-by-hop transfer 

transmitter/receiver 1406 of a specified output interface. technique, that is, by decrementing the TTL value of the 

Packets transmitted and received by the core node 1400, layer-3 header in each router, can be provided for the layer-3 

as in the case of the edge node 1300, also include control header when the packet is output from the LSP. 

messages for establishing and releasing LSPs. The control 65 According to the LDP used in the aforementioned 

messages are analyzed in a control message processor 1402, technique, it is not demanded that the respective nodes 

and contents of the LSP-control processing to be executed exchange information concerning the hop-count (indicated 
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by Ho in FIGS. 2(6) and 2(c)) which is the number of hops According to this transfer procedure, the ingress node 301 

from the ingress node 201 to the egress node 207. If the has stored the number of hops from the ingress node 301 to 

bop-count information is supposed to included in the control the egress node 307 and decrements the TI L field value of 

message such as a label mapping message, Ho-1 may be foe generic label header (and/or the layer-3 header) by the 

filled in such information. Accordingly, an LSP may be 5 number of hops (6 bops in FIGS. 3(a)-3(c)). With this 

established by transferring a label request message from the arrangement, the TIL value of the layer-3 header when a 

mgressnode201totliecg rc ssiiode207andbysendingback P acket • s ° ut P ul frornthe egress node 307 cao be set as the 

a label mapping message sequentially from the egress node "~ v ^ e as the TTL value, which is supposed to be 

207 to the mgrtss node 201 (FIG. 2(b)). Alternatively, the bv , a co°yennonal techmque, w, by decrements 
it-i • • , v u V _ , . Aamw% 11~ , n the TTL value of the layer-3 header in each router. That is, 

label assigning procedure may be performed independently 10 . . , ,J . . , - f tU 

. _ • uu • a /TTTf %/ \\ in the egress node 307, the TTL value provided for the 

between neighboring nodes (FIG. 2(c)) ^ Qf a ^ to be J ^ 

If, on the other hand the layer-2 header or^nally pos- de ^ menting mc ^ of ^ gcneric label header (or 
sesses a label field, which is implemented by ATM or frame ^ h 3 hcadcr) of ±c ^ b OQC> ^ mat ^ 

relay, each node can perform label switching without the TTL value equal to the TTL value calculated in conventional 
generic label header shown m FIG. 1. That is, packets are is ^ ^ obUmed 

^ wi)v^ ^a™^^ According to the LDP employed in the aforementioned 

of the Wl/VOor DLQ field in an ATM cell header or ^ proccdurc> ^ q{ the corc nodcs 302 

irame relay Deader as tne laoei. through 306 manages the information concerning hop-count 

In thiscase, even if the genenc label header shown in FIG. (indicated by Ho in FIGS. 3(b) and 3(c)) from that core node 
1 is added to the layer-3 packet, intermediate nodes of an 20 to the ^ Qode 397 by ^ me Lsp.status manager 
LSP may not check or update the TTL value. Thus, calcu- 1401 mustrat ed in FIG. 14, and also, the ingress node 301 
lations of the T1X value, which are conducted in the first fc fequired to manage the information concerning the hop- 
example, are not performed m the intermediate nodes. omml from ^ ingress node 301 to the egress 307 by 

Accordingly, a second example is discussed below with ^ the LSP-status manager 1302 shown in FIG. 13. 
reference to FIGS. 3( fl H c ) of P 3 ^** transfer performed on me & established by transferring a label request 

an LSP in a case where none of the intermediate nodes meS sage from the ingress node 301 to the egress node 307 
executes TTL processing, because, for example, the layer 2 and 5y sending back a label mapping message from the 
is based on ATM. egress node 307 to the ingress node 301. The hop-count Ho 

An ingress node 301 of the LSP first checks the stream ^ is included in the label mapping message from the egress 
information table 701 shown in FIG. 7 by using, as a key, noc j c 397, and each core node transfers the message to its 
stream information (for example, destination layer-3 upstream node while incrementing the hop-count Ho one- 
address, source layer-3 address, and so on) obtained by by-one (FIG. 3(b)). Alternatively, even without sending a 
referring to the header of a received layer-3 packet, and fafoi request message, the egress node 307 may voluntarily 
determines the output interface and the TIL value of a 35 multicast a label mapping message to its upstream side, and 
generic label header to be provided. The ingress node 301 on i y the upstream core node 306 relating to a stream 
also determines the VPI/VCI value and writes it into an ATM indicated in the label mapping message may actually receive 
cell header. The resulting ATM cell is then output from the the label mapping message, increment Ho by one, and 
determined output interface. More specifically, a generic multicast the label mapping message. Thus, the label map- 
label header is added to a packet, which js then provided ^ p m g message whose Ho is sequentially incremented up to 6 
with an ATM adaptation layer (AAL) trailer. The resulting hops may be transferred to the ingress node 301 by the 
packet is then formed into segments having a fixed length, similar operation of the core nodes 305 through 302. 
and the cell header is then provided. Y et alternatively, the label assigning procedure may be 

In the ingress node 301, the TTL value of the generic label performed independently between neighboring nodes. In 
header to be provided for the packet to be output is obtained 45 this case, a node that transmits a label mapping message to 
by decrementing the TTL value of the layer-3 header of the its upstream node writes into the label mapping message the 
received packet by the number of hops in the LSP (by 6 hops current hop-count information Ho which represents the 
in FIG. 3(a)). number of hops from the node to a currently-recognized 

By referring to the label information table 801 shown in egress node. Upon recognizing that the hop-number infor- 
FIG. 8 based on the VPI/VCI value of the received cell, each 50 mation Ho has been changed based on a notification from its 
of downstream label switching routers 302[\N]306 deter- downstream node, the node reports new hop-count informa- 
mines the output interface and the VPI/VCI value to be tion Ho to its upstream nodes by means of a control message 
provided for a cell to be output, and then writes the deter- (FIG. 3(c)). TTiis control message for reporting the updated 
mined VPI/VCI value into the cell. The resulting cell is then hop-count may be a separate message (updating message) 
output from the determined output interface. The above- 55 dedicatedly used for updating the hop-count information, or 
described transfer procedure can be realized by processing may be the label mapping message which is re-transmitted 
only an ATM cell header (generally, the layer-2 header and contains the updated hop-count information, 
including frame relay). It is thus unnecessary to check or In the example shown in FIGS. 3(a)-3(c), the connection 
update the individual fields of the generic label header identifier (VPI/VCI or DLCI) of the ATM header or the 
shown in FIG. 1 inserted between the layer-2 header and the 60 frame relay header is used as a label value for performing 
layer-3 header. label switching. However, even if a layer-2 network between 

Ultimately, by referring to the VPI/VCI value of the neighboring label switching nodes is based on ATM or frame 
received cell header, an egress node 307 confirms that it is relay, the connection identifier of the ATM header or the 
a terminating point of the LSP and then reconstructs the frame relay header may not be used for label switching, 
packet. The layer-3 header of the packet is then processed, 65 More specifically, by utilizing an AIM connection or a 
and the resulting packet is output from a specified output frame relay connection merely as a physical link, each node 
interface. of an LSP may perform label switching based on the label 
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value of the generic label header shown in FIG. 1. In this meeting the TTL value), the TTL value is calculated in the 

case, the TTL processing procedure similar to that discussed node 403 by decrementing by one (one hop) the TTL value 

with reference to FIGS. 2(fl)-2(c) is performed in the of the generic label header received from the ATM network, 

individual nodes. Whether the number by which the TTL value is to be 

In another network environment, a single LSP may 5 decremented is one (default) or the number of hops (two or 

include two types of segments, that is, segments that per- more) from the node 403 to a node that subsequently 

form label switching by utilizing the label value of the processes the TTL value of the generic label header is 

generic label header shown in FIG. 1, and segments that determined by referring to the label information table 801. 

perform label switching by utilizing the label value of the Upon receiving the PPP frame, a downstream label 

layer-2 header based on ATM or frame relay. TTL process- 10 switching router 404 processes the PPP header and then 

ing executed in such a network environment is described searches the label information tabic 801 by using, as a key, 

below as a third example with reference to FIGS. 4(a)~4(</). the label field (and CoS field if necessary) of the received 

Transition of the TTL value of the layer-3 header and the generic label header, thereby determining the output inter- 
generic label header, and the hopneount management pro- face (in this example, PPP link interface), the type and value 
cedure are shown in FIGS. 4(a)-4(</)- In this example, as 15 of output label, and the number by which the TTL value is 
discussed above, a single LSP includes segments that per- to be decremented (in this example, one). The generic label 
form label switching by using the ATM VPI/VCI value, header is then updated and provided with a PPP header, 
segments that perform label switching by using the label thereby outputting the resulting frame, 
value of the generic label header, as in PPP, and segments Further, a downstream label switching router 405 searches 
that perform label switching by frame relay DLCI. 20 the label information table 801 by using, as a key, the input 

An ingress node 401 of the LSP first checks the stream label value of the received generic label header, and deter- 

information table 701 shown in FIG. 7 by using, as a key, mines the output interface (in this example, frame relay 

stream information (for example, destination layer-3 interface), the output label type (DLCI) and the output label 

address, source layer-3 address, and so on) obtained by value, and the number by which the TTL value is to be 

referring to the header of a received layer-3 packet, and decremented (the number of bops from the node 405 to a 

determines the output interface (in this example, ATM node 407 that subsequently processes the TTL value of the 

interface) and the TTL vahie Of a generic label header to be generic label header). 

provided. The ingress node 401 also determines the output In the router 405, the number of hops (2) in the frame 

label value (in this example, the VPI/VCI value) and adds it relay network is determined. The generic label header is then 

to an ATM cell header. Thereafter, an ATM cell provided updated, and also, the obtained DLCI value is provided for 

with the ATM cell header is output from the determined the frame relay header and the resulting frame is output. In 

output interface. this case, the label value of the generic label header provided 

The TTL value of the generic label header to be provided in the output frame is not used for switching in a down- 

for a packet to be output from the ingress node 401 is 35 stream router 406 (instead, the DLCI value of the layer-2 

acquired by decrementing the TTL value in the layer-3 header is used for switching in the node 406). Tnus, a value, 

header of the received layer-3 packet by the number of hops which is meaningful for switching, may not be filled in the 

from the ingress node 401 to a node 403 that subsequendy label field of the generic label header, 

processes the TTL.value of the generic label header (by the Then, the label switching router 406 searches the label 

number of nodes performing label transfer by using the ^ information table 801 by using, as a key, the DLCI value of 

VPI/VCI as a label, i.e., two, in FIG. 4(a)). The number by the frame header of the received relay frame, and then 

which the TTL value is to be decremented can be obtained identifies that the output label, as well as the input label, 

by checking the stream information table 701. represents a DLCI of the frame relay header. Processing of 

Upon receiving the ATM cell, a downstream label switch- the TTL value of the generic label header is thus skipped, 

ing router 402 searches the label information table 801 4 s ^ onl y me DCU value fc updated. The resulting frame is 

shown in FIG. 8 by using, as a key, the input VPI/VCI value then transferred to its downstream node 407. 

of the cell header, and determines the output interface and The node 407, which serves as the egress node of the LSP, 

confirms that the type of output label assigned to the checks the DLCI value of the frame header of the received 

corresponding LSP is a VPI/VCI of the cell header. The label frame relay and confirms that the node 407 is a terminating 

switching router 402 then writes the value of output label 50 point of the LSP. Thus, the node 407 removes the frame 

obtained from the label information table 801, which is a relay header, and also checks and deletes the generic label 

VPI/VCI value, into the cell header and outputs the cell from header. After processing the layer-3 header, the packet is 

the determined output interface. In this case, since label output from a determined interface (or the node 407 may be 

switching is performed only by processing the cell header, a receiving host). 

the fields including the TTL value of the generic label header 55 According to the aforementioned third example shown in 

provided for the layer-3 packet are not checked or updated. FIGS. 4{dy-4(d) J each of the ingress node 401 and the 

A further downstream label switching router 403 searches intermediate nodes 403, 404, and 405 that process the 

the label information table 801 by using, as a key, the input generic label header stores the number of hops from each 

VPI/VQ value of the cell header of the received ATM cell, node itself to a node that subsequently processes the generic 

and determines the output interface (in this example, a PPP 60 label header. The TTL field value of the generic label header 

link interface), the output label value (in this example, the is decremented by this stored number of hops (two hops in 

type of output label is a label in the generic label header) the node 401, one hop in the nodes 403 and 404, and two 

assigned to the corresponding LSP, and the TTL value to be hops in the node 405). Accordingly, the TTL value provided 

filled in the generic label header. In a case where its for the layer-3 header in the egress node 407 can be obtained 

downstream node 404 fills a label value in the label field of 65 by decrementing the TTL value of the received generic label 

the generic label header (where the downstream node 404 header by one. It is thus possible to appropriately set the TTL 

executes processing of the generic label header by decre- value. With this arrangement, the TTL value of the layer-3 
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header to be provided when a packet is output from the ferred in the nodes 405, 406, and 407, as in the case of the 

egress node 407 of the LSP can be set to the same value as nodes 401, 402, and 403. 

would be obtained by a conventional hop-by-hop transfer Upon receiving the label request message or the label 

technique, i.e., by decrementing the TTL value of the layer-3 mapping message as discussed above, an intermediate node 

header in each node 5 determines whether the message is to be passed to the 

According to the LDP employed to realize the aforemen- downstream node or to the upstream node writing the Ho 

™y e y j value into the label mapping message) like the nodes 402 

honed transfer procedure, the mdmdual nodes (mending and 4o 6 , or ^ label ^^TmessasTis to be terminated at 

the ingress node 401) processing the generic label header ^ ^ ^ ^ ^ ^ ffl returned to 

collect and store the hop-count information concerning the me upstream ^de like the nodes 403 through 405. Such a 

aforementioned number of hops (represented by Ho in ™ determination may be performed by comparing the type of 

FIGS. *Q>Xt))- output label with the type of input label of the LSP to be 

For example, the LSP may be established by transferring established If it is found that the node performs generic 

a label request message from the ingress node 401 to the processing (updating the TTL value of the generic label 

egress node 407, and by sending back a label mapping header), the node determines to terminate the message. If it 

message from the egress node 407 to the ingress node 401, jg found that the node does not perform generic label 

as illustrated in FIG. 4(b). In this case, the hop-count processing, the node determines to pass the message to the 

information (Ho«al) is first included in the label mapping downstream or upstream node. 

message sent from the egress node 407. Upon receiving the j f thc nodc cxccutcs generic label processing (i.e., if the 

label mapping message, an intermediate node compares the ^ node ^ 403 404, 405, or 407), the node may also determine 

type of output label with the type of input label of the LSP whether the label mapping message without Ho can be sent 

to be established and determines whether the intermediate ^ me case 0 f me no d e 404 or 405) or the label mapping 

node is to process the generic label header (whether the message with hop-count information (Ho-1) is to be sent (as 

intermediate node is to update the TTL value of the generic m me case 0 f noc j e 403 or 407) based on the type of input 

label header). If the outcome of the determination is yes, the ^ igfoel. jf necessary, message exchange may be carried out 

intermediate node sends the label mapping message indi- between neighboring nodes for me node to check whether its 

eating that the hop-count information is one (Ho»l) to its upstream node executes generic label processing, 

upstream node. Otherwise, the intermediate node fills in the Alternatively, all of the nodes 403, 404, 405, and 407 may 

label mapping message a new hop-count information (Ho>« transmit a label mapping message without Ho, and if the 

2) obtained by incrementing the hop-count information ^ upstream node receiving this message is the node 402 or 

received from the downstream node by one, and transmits 406, the upstream node may interpret that Ho-1 and transfer 

the label mapping message to its upstream node. me meS sage including the incremented Ho to its upstream 

In the LSP shown in FIG. 4(a), the generic label header node 401 or 405. 

is processed in the node 403 at which the type of label is As in the modification shown in FIG. 3(c), the label 

changed from ATM (VPI/VCI) to PPP (generic label) and in 35 assigning procedure may be executed independently 

the node 405 at which the type of label is changed from PPP between neighboring nodes, as illustrated in FIG. 4(a). A 

(generic label) to frame relay (DLCI). Also, the node 404 noc j e that is to transmit a label mapping message to the 

located at a boundary of the PPP links processes the generic upstream node writes into the message current hop-count 

label header though the type of label is not changed there. information Ho that represents the number of hops from the 

Accordingly, the label mapping message is transferred ^ node to a currently-recognized node on the nearest down- 

from the downstream node to the upstream node, as illus- stream side as executing generic label processing. Upon 

trated in FIG. 4(b), while changing the Ho value contained recognizing that the hop-count information Ho (which is 

in the label mapping message. Alternatively, without send- notified by the downstream node) has been changed, the 

ing a label request message, the egress node 407 may node is required to report new hop-count information to its 

voluntarily multicast a label mapping message to its 45 upstream node by way of a control message. This control 

upstream side. Then, only the intermediate node relating to message may be a separate message dedicatedly used for 

a stream contained in the label mapping message may updating the hop-count information, or may be the label 

actually receive the message and transfer it to its upstream mapping message resent with the updated hop-count infor- 

side while, if required in accordance with the above- mation. 

described determination, incrementing the Ho value in the 50 The fourth and fifth examples of TTL processing executed 
message. in another network environment, where a single LSP con- 
In an alternative approach to sending messages, as shown tains segments that perform label switching by utilizing the 
in FIG. 4(c), the sequence of first transferring the label label value of the generic label header shown in FIG. 1 and 
request message sequentially from an upstream node to a segments that conduct label switching by utilizing the label 
downstream node and then sending back the label mapping 55 value of the laycr-2 header, is described below as with 
message accompanied by appropriate hop-count information reference to FIGS. 5(a)-5(a f ) and 6(a)-6(d). In the third 
Ho sequentially from the downstream node to the upstream example illustrated in FIG. 4, label switching segments are 
nodes is executed within one zone of the LSP in which the arranged in the order of ATM, generic label, and frame relay, 
generic label header is not processed. That is, the label In FIGS. 5(a)-S(d) and 6(a}-6(d), however, label switching 
request message is transferred in the order of the nodes 401, 60 segments are arranged in the order of generic label, frame 
402, and 403, and the label mapping message is sent back in relay, and ATM. In this network environment, two different 
the order of the nodes 403, 402 (Hool), and 401 (Ho=2). techniques of TTL processing of the generic label header, 
In this case, label assigning by the label mapping message which are respectively illustrated in FIGS. S(a)-S(d) and 
including Hool or not including any Ho is performed FIGS. 6(a)-6(d), may be considered, 
independently within each of the zones between the nodes 65 As the fourth example shown in FIGS. 5(a)-5(</), packet 
403 and 404 and between the nodes 404 and 405. The label transfer is performed in an LSP in a manner similar to the 
request message and the label mapping message are trans- third example shown in FIGS. 4(a}-4(d). 
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An ingress node 501 of the LSP first checks the stream 
information table 701 shown in FIG. 7 by using, as a key, 
stream information (for example, destination layer-3 
address, source layer-3 address, etc.) acquired by referring to 
the header of the received layer-3 packet, and determines the 
output interface (in this example, a LAN interface) and the 
content of the generic label header (label value, CoS value, 
and TTL value) to be attached. The ingress node 501 then 
attaches the generic label header and the layer-2 header to 
the frame and outputs the resulting layer-2 frame from the 
determined output interface. In this case, the TTL value 
(label_ttl) of the generic label header to be provided in the 
ingress node 501 is calculated by decrementing the TTL 
value (ip_ttl) of the received layer-3 header by one, since a 
downstream node 502 is also able to process the generic 
label header. 

Hie node 502, upon receiving the frame, searches the 
label information table 801 by using, as a key, the label value 
of the generic label header, and performs label switching 
(decrementing the TTL value of the generic label header by 
one) by providing the generic label header to the frame to be 
output. A downstream node 503 that has received the frame 
then searches the label information table 801 by using, as a 
key, the label value of the generic label header. Based on the 
search result, the node 503 performs label switching and 
attaches the frame relay header as a label to the frame to be 
output. In the node 503, the TTL value to be decremented, 
described in the label information table 801, is two 
(therefore, the node 503 decrements the TTL value of the 
generic label header by two). This is because the node that 
subsequently processes the generic label header is two hops 
away (node 505). A node 504 searches the label information 
table 801 by using the frame relay header (DLCI) as an input 
label, and also provides the frame relay header (DLCI) 
including an output label to the frame to be output (the 
generic label header is not processed). 

The node 505 searches the label information table 801 by 
using the frame relay header (DLCI) as the input label so as 
to obtain the output interface (ATM) and the output label 
(VPI/VCI). Although the label field value of the generic 
label header is not used for label switching, the TTL value 
(label__itl) of the generic label header provided for the 
layer-3 packet is checked and updated when the frame relay 
frame is converted into an ATM cell The label_ttl is 
decremented by two, which is the number of bops in the 
zone where label switching is performed by using the 
VPI/VCI label on downstream side of the node 505. 

By referring to the VPI/VCI value of the received cell 
header, the node 507 confirms that it is a terminating point 
of the LSP. The node 507 then assembles the AAL frame, 
and checks and removes the generic label header. After 
executing the layer-3 processing, the resulting packet is 
output from a determined interface (or the node 507 may be 
a receiving host). 

According to the fourth example discussed above, the 
TTL value of the generic label header is decremented by an 
adequate number of hops in (a) the node 503 that performs 
label switching by searching the label inform nation table 
801 using the label value of the generic label header as a key, 
(b) the node 502 that updates the label value of the generic 
label header based on the search result of the label infor- 
mation table 801, and (c) the node 505 that is not required 
to check or update the label value of the generic label header 
but handles different types of headers (for example, frame 
relay header and ATM cell header) between the input label 
and the output label. As a result, the TIL value of the layer-3 
header to be provided when a resulting packet is output from 
the egress node 507 of the LSP can be set to the same value 
as the TTL value would be obtained by decrementing the 
TTL value one-by-one in each router. 



To implement the above method, either one of various 
LDPs similar to those of the third example shown in FIGS. 
4(b) through 4(d) can be employed. That is, the LDPs 
include a technique of sequentially transferring a label 

5 request message from the ingress node 501 to the egress 
node 507 of the LSP and sending back a label mapping 
message from the egress node 507 to the ingress node 501, 
as illustrated in FIG. 5(b), a technique of transferring a label 
request message and sending back a label mapping message 
between both ends of each zone formed by nodes that do not 

10 perform ITL processing of the generic label header, as 
shown in FIG. 5(c), and a technique of updating hop-count 
information as required by conducting label assigning inde- 
pendently between neighboring nodes, as illustrated in FIG. 
5(d). According to the LDPs indicated in this fourth 

15 example, a node (for example, the node 505) executes TTL 
processing even if it uses a DLCI of a frame relay header as 
the input label and uses a VPI/VCI of an AIM cell header 
as the output label, that is, the TTL value of the generic label 
header is decremented even if neither of the input label nor 

20 the output label is described in the generic label header. 
In the fifth example illustrated in FIGS. 6(a)-6(d), in 
contrast to the fourth example shown in FIGS. S(ay~5(d) f 
TTL processing of the generic label header is not executed 
at the node 505 at which the label for label switching is 

25 changed from the frame relay header to the ATM cell header. 
Label transfer in the fifth example is performed from the 
ingress node 501 up to the intermediate node 504 similarly 
to those shown in FIG. 5(a). 

The node 505 searches the label information table 801 by 

30 using the frame relay header (DLCI) as the input label so as 
to obtain the output interface (ATM) and the output label 
(VPI/VCI). Since the label field value of the generic label 
header is not used for switching, the TTL value (label_ttl) 
of the generic label header provided for the layer-3 packet is 
not updated, though the frame relay frame is converted into 

35 the ATM cell. Accordingly, the nodes 504, 505, and 506 do 
not execute TTL processing of the generic label header, and 
thus the intermediate node 503 decrements the TTL value by 
the number of hops, i.e., four, from the node 503 to the node 
507 that subsequently performs TTL processing. 

40 Processing executed by the node 507, which serves as the 
egress node, is similar to that of the fourth example. 

In the fifth example, the TTL value of the generic label 
header is decremented by an adequate number of hops in (a) 
the node 503 that performs switching by searching the label 

45 information table 801 using the label value of the generic 
label header as a key, and (b) the node 502 that updates the 
label value of the generic label header based on the search 
result of the label information table 801. As a consequence, 
the TTL value of the layer-3 header to be provided when a 

50 packet is output from the egress node 507 of the LSP can be 
set to the same value as would be acquired by decrementing 
the TTL value of the layer-3 header one-by-on in each 
intermediate router. 
To implement the above method, either one of various 

55 LDPs similar to those of the fourth example shown in FIGS. 
5(b) through 5(d) may be employed. That is, the LDPs 
include a technique of sequentially transferring a label 
request message from the ingress node 501 to the egress 
node 507 of the LSP and sending back a label mapping 
message from the egress node 507 to the ingress node 501, 

60 as illustrated in FIG. 6(b), a technique of transferring a label 
request message and sending back a label mapping message 
between both ends of each zone formed by nodes that do not 
perform TTL processing of the generic label header, as 
shown in FIG. 6(c), and a technique of updating hop-count 

65 information as required by conducting label assigning inde- 
pendently between neighboring nodes, as illustrated in FIG. 
6(<i). The LDP executed in the fifth example shown in FIGS. 
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6(b) through 6(d) is different from that shown in FIGS. 5(b) 
through 5(d) in that the node 505, which uses the DLCI of 
the frame relay header as the input label and the VPI/VCI of 
the ATM cell header as the output label, determines that the 
node 506 is not to perform TTL processing. 

That is, it is determined that the node 505 does not process 
the generic label header (does not update the TTL value) if 
neither of the input label nor the output label represents the 
generic label (instead, the label is ATM VPI/VCI or frame 
relay DLCI), regardless of whether the type of input label 
and the type of output label concerning a certain LSP are the 
same or different. Then, the node 505 fills in the label 
mapping message a new Ho value obtained by incrementing 
the Ho value received from the downstream node by one, 
and then transmits the message to the upstream node. 

In the LDP shown in FIG. 5(d) or 6(d), even if the nodes 
of the LSP have already informed the hop-count to their 
upstream nodes when assigning the labels by the label 
mapping message, they may be required later to report an 
updated hop-count to the upstream nodes by way of a control 
message, in accordance with a new hop-count informed by 
the downstream nodes when labels are assigned later. The 
updated hop-counts in the nodes 505 and 504 shown in FIG. 
5(d) are Ho=-l and 2, respectively, while the updated hop- 
counts in the nodes 505 and 504 shown in FIG. 6(d) are 
Ho-3 and 4, respectively. The control message may be a 
separate message dedicatedly used for updating the hop- 
count, or may be the label mapping message with updated 
hop-count information, as in the case of FIG. 4(<Q or 3(c). 

To summarize the respective cases discussed above, the 
operation performed by each node of an LSP upon executing 
the label distributing procedure will be described below. 

FIG. 9 is a flowchart illustrating an example of the 
operation performed by each node upon receiving a label 
mapping message from the downstream node when the LDP 
illustrated in FIG. 4(b), 4(c), 5(b), 5(c), 6(b), or 6(c) is 
executed. 

Upon receiving a label mapping message concerning a 
certain stream from the downstream node, information indi- 
cating the stream for which a label is requested to be 
assigned, the type of downstream label (ATM label, frame 
relay label, or generic label), and hop-count information Ho 
arc checked and stored (step S-l). 

It is then determined whether a label request message 
relating to the same stream as that indicated in the received 
label mapping message has been received from the upstream 
node (step S-2). If the outcome of step S-2 is no, the 
processing is completed, and the hop-count information Ho 
received from the downstream node is stored while relating 
it to the stream. In this case, if the node receives a packet 
belonging to the stream later, it operates as the ingress node 
of the LSP. That is, the value obtained by decrementing the 
TTL value (ip_ttl) of the layer-3 header of the received 
packet by the hop-count Ho is set as the TTL value (label_ 
ttl) of the generic label header. The packet is then provided 
with a determined label value and is transmitted onto the 
LSP. 

If the stream corresponding to the stream assigned with 
the label by the downstream node is waiting for label 
assigning on the upstream path (i.e., the result of step S-2 is 
yes), the label value to be assigned is determined, and the 
type of upstream label is checked (step S-3). Upon checking 
the types of upstream label and downstream label, it is 
determined whether the node is to perform TTL processing 
of the generic label header for the LSP to be established (step 
S-4). The basis for this determination will be discussed in 
detail below by way of specific examples. 

If the result of step S-4 is yes, the hop-count information 
Ho is set to be one (step S-5), and the label mapping message 



is sent to the upstream node that is waiting for labe l 
assigning (step S^7). If it is found in step S-4 that TTL 
processing of the generic label header is not to be performed 
in this node, the hop-count information Ho is calculated by 
5 incrementing the Ho value received from the downstream 
node by one (step S-6), and the label mapping message is 
transferred to the upstream node that is waiting for label 
assigning (step S-7). With step S-7, the information corre- 
sponding to the content of the label mapping message 
processed in this node is generated as an entry of the label 
10 information table 801 shown in FIG. 8. Thereafter, upon 
receiving a frame provided with the label value reported to 
the, upstream node, the node determines the output interface 
and the output label value to be provided for the frame to be 
transferred, while serving as an intermediate node. The 
15 frame with the output label is then transmitted on the LSP. 
FIG. 10 is a flowchart specifically illustrating an example 
of the determination (step S-4 of FIG. 9) of whether TTL 
processing of the generic label header is executed in the 
given node which has received the label mapping message 
20 from the downstream node. As parameters for making that 
determination, the type of input label and the type of output 
label are utilized. The label types and thee range of label 
values may have been negotiated between neighboring 
nodes which: are adjacent to each other physically or 
25 logically, and may be stored in the individual nodes. 

In this example, it is first checked whether either of the 
type of input (upstream) label or output (downstream) label 
is the generic label header (step S-U). If the outcome of step 
S-ll is yes, it is determined that TTL value processing of the 
30 generic label header is to be executed in this node, because 
the node processes the generic label header for label switch- 
ing. If neither of the type of input label nor output label is 
the generic label header (for example, it is a layer-2 header), 
it is further determined whether the types of labels are 
different (for example, ATM VPI/VCI or frame relay DLCI) 
35 (step S-12). If the result of step S-12 is no, it is determined 
that the TTL value of the generic label header is not to be 
processed (since the mere ATM switching or frame relay 
switching is performed) in this node. 

If it is found in step S-12 that the types of labels are 
40 different (for example, the downstream label is ATM VPI/ 
VQ and the upstream label is frame relay DLCI), it is 
determined that TTL processing of the generic label header 
is to be executed if the control technique shown in FIGS. 
5(a)-5(d) is employed. On the other hand, it is determined 
45 that TTL processing of the generic label header is not to be 
executed if the control technique shown in FIGS. 6(a)-6(d) 
is used. Either case is possible according to an actual 
implementation of label switches, though FIG. 10 illustrates 
the determination in the case of control technique illustrated 
50 in FIGS. 5(a)-5(d). 

FIG. 11 is a flowchart illustrating an example of the 
operation performed by each node upon receiving a label 
request message from the upstream node when the LDP 
illustrated in FIG. 4(d), 5(d), or 6(d) is employed. The 
operation represented by this FIG. 11 is performed in the 
case where the label assigning procedure is conducted 
independently between neighboring nodes, while FIG. 9 is 
for the case where the label request message is sequentially 
transferred from one node to another node and the label 
mapping message is sequentially sent back from that another 
60 node to that one node. According to the operation shown in 
FIG. U, as in the case of the operation shown in FIG. 9, each 
node requires a mechanism for managing appropriate hop- 
count information (information concerning the number of 
nodes consecutively located that do not perform TTL 
65 processing). 

Upon receiving a label request message concerning a 
certain stream from the upstream node (step S-21), the label 
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value to be assigned is determined, and also, it is checked 
whether the downstream label relating to the requested 
stream has been assigned (step S-22). 

If the absence of the downstream label is recognized (or 
if this node is topo logically the egress router), the hop-count 5 
information (Ho-1) concerning the stream is stored (step 
S-24). The hop-count information Ho, together with the 
label value (and label type), is then informed to the upstream 
node by using the label mapping message (step S-26). 

Conversely, if the presence of the downstream label is 10 
recognized in step S-22, it is determined, based on the type 
of existing downstream label and from the type of upstream 
label to be assigned, whether this node is to process the TTL 
value of the generic label header (step S-23). This determi- 
nation may be made according to the procedure, for 15 
example, shown in FIG. 10. If the outcome of step S-23 is 
yes, the hop-count value (Ho-1) relating to the stream is 
stored (step S-24). If the result of step S-23 is no, the 
hop-count value Ho obtained by incrementing the value Ho 
received from the downstream node by one is stored (step 
S-25). Then, the stored hop-count information Ho, together 
with the label value (and the label type), is reported to the 
upstream node by using the label mapping message (step 
S-26). 

FIG. 12 is a flowchart illustrating an example of the 
operation performed by each node upon receiving a label 25 
mapping message (or label-updating message, which will be 
discussed below) from the downstream node when the LDP 
illustrated in FIG. 4(d), 5(d), or 6(d) is executed as the 
control procedure. 

Upon receiving a label mapping message from the down- 30 
stream node, the hop-count information Ho included in the 
message is stored together with the downstream label (step 
S-31). It is then checked for the presence of the upstream 
label concerning the same stream as that contained in the 
received label mapping message (step S-32). 35 

If the outcome of step S-32 is no, the processing is 
completed. If the result of step S-32 is yes, it is determined, 
based on the type of upstream label and the type of down- 
stream label, whether this node is to process the TTL value 
of the generic label header (step S-33). This determination 40 
may be made according to, for example, the procedure 
shown in FIG. 10. 

If the outcome of step S-33 is yes, the processing is 
completed, since the hop-count information (Ho»l) has 
been already informed to the upstream node. If the result of 45 
step S-33 is no, it is determined whether or not the hop-count 
value (Ho+1), which is a new hop-count obtained by incre- 
menting the Ho value received from the downstream node 
by one, is equal to that stored as already notified to the 
upstream node (step S-34). If the outcome of step S-34 is 5Q 
yes, the processing is completed. If the result of step S-34 is 
no, the new hop-count (Ho+1) is reported to the upstream 
node as updated hop-count information Ho (step S-35). To 
report this updated hop-count information, an updating 
message, which is newly defined for informing a correct 
hop-count value, may be sent, or a label mapping message 55 
having the updated hop-count value may be sent. 

In the examples stated above, only a point-to-point LSP 
has been discussed. However, the above-described examples 
are applicable to a multipoint-to-point (stream merge) LSP 
in which a plurality of different upstream labels are related 60 
to a single downstream label. 

As an example, the following case may be considered. In 
the example shown in FIGS. 6(a)-6(d), in the point-to-point 
LSP established for a certain stream in which the ingress 
node 501 through the egress node 507 are sequentially 65 
arranged, a label request message for establishing an LSP for 
the same stream is sent from an upstream node 508, which 
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is different from the current upstream node 502, to the 
intermediate node 503. 

The processing executed by the node 503 in response to 
this request can be realized by applying any of the tech- 
niques shown in FIGS. 6(b) through 6(d) as follows. 

The node 503 that has received the label request message 
from the upstream node 508 operates in a way similar to 
FIG. 11. That is, the node 503 checks whether the down- 
stream label concerning the requested stream has been 
already assigned between the nodes 503 and 504. If the 
result is yes, it is determined, based on the type of label 
(frame relay DLCI) already assigned between the node 503 
and the downstream node 504 and the type of label to be 
assigned between the node 503 and the upstream node 508, 
whether the node 503 is to process the TTL value of the 
generic label header for a packet stream requested by the 
node 508. This determination may be made according to the 
procedure shown in FIG. 10. 

For example, if the type of new upstream label of the node 
508 is a generic label of a LAN, as well as the upstream label 
already assigned with the upstream node 502, the node 503 
processes the generic label. Accordingly, the hop-count 
information is stored, and the label value, together 
with the hop-count Ho-1 or without any hop-count 
information, is reported to the upstream node 508 by using 
a label mapping message. 

When a packet belonging to the stream is actually trans- 
ferred from the node 508, the node 503 refers to the label 
value of the received generic label header so as to determine 
the output interface and the frame relay DLCI value for the 
frame to be transferred to the downstream node 504, by 
searching the label information table 801. The output DLCI 
value is the same as that supposed to be obtained when a 
packet belonging to the same stream is received from the 
upstream node 502, because of the stream merge function in 
the node 503. The node 503 also decrements the TTL value 
of the generic label header by four in the example of FIGS. 
6(a)-6(d), as indicated in the label information table 801. 

Conversely, if the type of upstream label of the node 508 
is a frame relay DLCI, the node 503 recognizes that the type 
of upstream label is the same as that of the downstream label 
of the node 504, and determines that the node 503 is not 
going to perform TTL processing of the generic label header. 
Thus, the hop-count information Ho=5(-4+l) is newly 
stored and notified, together with the label value, to the 
upstream node 508 by using the label mapping message. 
Triis enables the upstream node 508 to send a packet with a 
TTL value decremented appropriately in advance. 

In this case, when the packet is actually transferred from 
the node 508, the node 503 refers to the DLCI value of the 
received frame relay header so as to determine the output 
interface and the output DLCI value for the frame to be 
transferred to the downstream node 504, by searching the 
label information table 801. However, the information con- 
cerning the number to be decremented is not described in the 
label information table 801 as indicated " — " in FIG. 8, and 
the TTL value of the generic label header is not processed in 
the node 503 regarding packets belonging to the stream and 
received from the node 508. 

In this manner, when an LSP is merged at a certain node, 
the TTL value of the generic label header may be processed 
or may not be processed according to from which upstream 
node a labeled frame is transferred to the certain node, 
though the frame provided with the same label is transferred 
to the same downstream node. The determination can be 
made based on a combination of the type of upstream label 
and the type of downstream label as described above. 

Although unicast communications are performed in the 
foregoing embodiment, the present invention is applicable to 
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multicast communications by slightly modifying the control with the nodes 404 and 408 by checking the label informa- 

procedure. An example of such a modification is as follows. tion table 801. For the labeled frame to be transferred to the 

FIG. 15(a) illustrates a network configuration which is node 404, the number (in this case, two) by which the TTL 

modified by providing additional nodes 408, 409, and 410 in ™lue is to be decremented is obtained from the label 

the network configuration shown in FIG. 4(a). In this 5 information table 801. Thus, into the generic label header of 

network, a point-to-multipoint (one-to-two in this example) frame to be output to the node 404, the node 403 writes 

LSP is utilized for layer-3 multicast communication. The foe output label and the TTL value decremented by two, 

main difference of the multicast LSP from unicast LSPs which represents the number of nodes (402) which do not 

(point-to-point LSP, and multipoint-to-point LSP) is the perform TTL processing upstream of the node 403 in 

position in the LSP of the node at which the TTL value of 10 addition to the node 403 itself. For the labeled frame to be 

the generic label header is decremented. transferred to the node 408, the number by which TTL value 

T f ... « M • is to be decremented is not described in the label information 

In the case of unicast communications, when a series ot . , t OM . r . , . • - ^ , 

, , . • 4 j c: ~- «~T« • t „ i table 801, since TTL processing of the genenc label header 

k nodes that do not perform TTL processing exists down- r . _ » , , !L ♦ . *u a Ana • * 

r . r . c i cn *u „,* • a~ of the frame to be output to the node 408 is not executed. 

stream of a certain node of an LSP, the certain node __. . . r . - . . . , - AO . M ... 

j * *u ttt i u /L . i\ ,* u.*~ M i« TTL processing is not executed at the node 408, since both 

decrements the TTL value by a number (k+1) in advance. In 1S . f _ » . , . . , • ^ 

4 . c u . . • V JL ™„ k. input label and output label are ATM labels. Then, its 

the case of multicast communications, however, it may be , * , A A n , ... ™w , , ' , M 

u , , ... , m „ Mt Jr\ a „u^ n ^ downstream node 409 decrements the TTL value because 

difficult to apply this decrementing technique, since the 4 . . . . , . . A ™. , . , , _ , . 

, rt- L~ j . i „ i „ M .i„ the mput label is an ATM label and the out put label is the 

number of hops from a certain node to a node subsequently i " . . . r 

performing TTL processing on one blanched link of an LSP generic label. , . , „ 

and that on another branched link of the LSP may be . In this case me TTL value is decremented by four, since 

different. Accordingly, when a series of k nodes that do not 20 Hl=4 included in the label request message has ^stored, 

perform TTL processing exists upstream of a certain node of number four represents the number of nodes (402, 403, 

an LSP, the certain node decrements the TTL value by a and 408) that do not perform TTL processing upstream of 

number (k+1) later. An example of the LDP which imple- the node 409 in addition to the node 409 itself, 

meets this technique is as follows. When the label assigning procedure is conducted inde- 

According to the procedure in which a label request 25 ^^tJS^T^ » ^^^^ 

message is transferred from the ingress node to the egress * . 16 < fl > m { ^ jrformation < g u K 

node of an LSP and a label mapping message is sent back <™f ? f **° mclud ^ m * e leque* message by each 

from the egress node to the ingress nodeTas shown in FIG. node - * ^ OWev ^l n ^ e il rcoeiV f a label request 

15(6), the information regarding the number of hops to be message transmitted from me upstream node, the node 

decremented is included iTthe label request messa^. Upon 30 updates the hop-count information which was previously 

receiving the label request message including the hop-count to to ^^^^i* ffluat ??f m " G - } 6 ^1 

information Hi-1 from the ingress node 401, the node 402 ™i en reporting the urxiated hop-count information to the 

recognizes that both upstream label and downstream label downstream node, an updating message, which is newly 

are ATM labels, and Tansmits the label request message f efincd for forming a correct hop-count value, may be 

having the liop-count information Hi-2(-l + l) to the node 3 5 tr * nsmit f t d i° r . a , ' a . bel request message may be 

403 re-transmitted by including the updated hop-count lnforma- 

" r . , , , _ . tion. The determination as to whether a message containing 

TJe LSP is branched off at the node 403 m the directions new hop . count (which ^ two or greater) information is 

of the node 404 and the node 408 Since the downstream ^ansmin^ can be made by a procedure similar to that 

label is the generic label (of a PPP link) m the direction of sn0 wn in FIG 10 

the node 404, TTL pressing of Ae generic ^ t^deri b 40 while the present mvention has described with 

to be Performed in the node 404. Thus, be node 403 ^ m considered to be the pre- 

transmits me label request message havmg the hop^unt McnibodiM 

mformauon Hid to the node 4M In contras^ smce toe ^ not to the disclosed embodiments. On the contrary, 

T^TrJf 18 ™ X™^ 1 m . th f ^ f ^ the invention is intended to cover various modifications and 

T^^^^^^f^^^^S^ 45 equivalent arrangements included within the spirit and scope 

to be executed m the node 408. Accordingly, jbe node 403 * ^ ^ of mc fo^^ ^ 

transmit the . label request message having the hop-count ^ to be ^ rded me broadest im^retation so as to encom- 

information Hi»3(-2+l) to the node 408. paS s all such modifications and equivalent structures and 

The node 408 passes the label request message onto the functions, 
node 409 by changing the hop-count information Hi-3 to 5Q individual functions described in the above-described 
Hi-4 (-3 +1). The node 404 passes the label request embodiments may be achieved by either software or 
message to the node 405 by maintaining the hop-number hardware, or any combination of software and hardware. For 
information Hi-1. The procedure is repeated in this manner examplej lhe control message processors 1303 and 1402, the 
until the message reaches the egress nodes of the respective Lsp.^^ manag ers 1302 and 1401, and the packet pro- 
directions, cessor 1304, shown in FIGS. 13 and 14, may be suitably 

The determination as to whether the hop-count informa- implemented by software, and the procedures explained 

tion Hi»l (or no hop-count information) is to be included, or with reference to FIGS. 9 through 12 may also be conve- 

the hop-count information obtained by incrementing the Hi niently implemented by software. Also, the above-described 

value received from the upstream node by one is to be embodiments according to the present invention may be 

included, in the label request message to be transmitted to conveniently implemented using conventional general pur- 

the downstream nodes, can be made according to a proce- 60 pose digital computers programmed according to the teach- 

dure similar to that shown in FIG. 10. If it is determined that mgs 0 f the present specification, as will be apparent to those 

the node performs TTL processing of the generic label skilled in the computer art. Appropriate software coding can 

header, the former case is applied. Otherwise, the latter case readily be prepared by skilled programmers based on the 

is applied. teachings of the present disclosure, as will be apparent to 

Thus, upon receiving a labeled frame (in this example, an 65 those skilled in the software art. Such a software package 

ATM cell) from the node 402, the node 403 at which the LSP can be a computer program product that employs a storage 

is branched off determines the output interfaces connected medium including stored computer code which is used to 
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program a computer to perform the disclosed function and 4. The method according to claim 1, further comprising a 

process of the present invention. step of: 

In addition to those already mentioned above, persons of transferring, by said each of the first type of nodes, the 

ordinary skill will realize that many modifications and packet received from an upstream node on the upstream 

variations of the above embodiments may be made without 5 «de to a downstream node on the downstream side by 

departing from the novel and advantageous features of the performing the label switching operation on the packet 

present invention. without updating said information. 

Accordingly, all such modifications and variations arc 5 Th e method according to claim 1, wherein the trans- 

rti^uiuui^y, ait auwu uj^univaviuuo au« T *"°"™' mittmg step by said each of the second type of nodes 
mtended to be included within the scope of the appended J^nd message including a defaulThop-count. 
claims The specification and examples are only exemplary. 10 6 ^ method accordin | t0 ^\ wherein me Gr- 
ille following claims define the true scope and spirit of the mining step by said each of the plurality of nodes determines 
invention. to update said information, when any one of the input label 

What is claimed is: and the output label is to be written into a header of the 

1. A method of managing a hop-count of a label switched packet, the header containing said information. 

path in a network, the label switched path being configured 1S 7. Tne method according to claim 1, wherein the deter- 
by a plurality of nodes for performing a label switching mining step by said each of the plurality of nodes determines 
operation on a packet by using an input label and an output not to update said information, when both the input label and 
label assigned to a packet stream including the packet, said the output label are to be written into a first header of the 
method comprising steps ofc packet, the first header being different from a second header 
determining, by each of the plurality of nodes, whether or 20 containing said information. . l j 
not said each of the plurality of nodes is to update . 8 ; ™» method according to claim 1, wherein the deter- 
information included in the packet when performing ste P ™* t of tbe plurahty of nodes determines 

the label switching operation on the packetTthe infor- to I^ZF* ^ 

. . . r j . . and a type of the output label are different from each other, 

matron being to represent how many nodes through 9 ^ method according to claim 1, wherein at least one 

which the packet has passed; ^ of ^ plurality of nodes operates as the first type of nodes 

transmitting, by each of a first type of nodes among the f or one packet to be transferred from one upstream node and 

plurality of nodes which determine not to update said operates as the second type of nodes for another packet to be 

information, when said each of the first type of nodes transferred from another upstream node, said one packet and 

is notified of a hop-count regarding the label switched said another packet belonging to the packet stream, 

path by a first neighboring node on one of an upstream 30 10. The method according to claim 1, wherein at least one 

side and a downstream side of said each of the first type of the plurality of nodes operates as the first type of nodes 

of nodes, a first message including an incremented for one packet to be transferred to one downstream node and 

hop-count obtained by incrementing the hop-count operates as the second type of nodes for another packet to be 

notified regarding the label switched path, to a second transferred to another downstream node, said one packet and 

neighboring node on another one of the upstream side 35 said ^^ei packet belonging to the packet stream, 

and the downstream side; and U Jhc mcthod accord ing to claun whcrcm at lcast one 

... m „ , , A . of the second type of nodes receives, as the second neigb- 

transmittmg, by each of a second type of nodes among the boring Qode , the first message from one first neighboring 

plurality of nodes which determine to update said node and the second message from another first neighboring 

information, a second message indicating that said each noc j c> ^ onc ^ neighboring node and said another first 

of the second type of nodes is to update said 40 ^g^ring no d e being on the label switched path for the 

information, to the second neighboring node. packet stream. 

2. The method according to claim 1, further comprising a 12. The method according to claim 1, wherein at least one 
step of: of the second type of nodes receives, as the second neigh- 
transferring, by said each of the second type of nodes, the boring node, one first message including one incremented 

packet received from an upstream node on the upstream 45 hop-count from one first neighboring node and another first 

side to a downstream node on the downstream side by message including another incremented hop-count from 

performing the label switching operation on the packet another first neighboring node, said one first neighboring 

and by updating the information included in the packet node and said another first neighboring node being on the 

based on the incremented hop-count, when said each of ^ swttched path for the packet stream 

the second type of nodes has^eceived the first message 50 13- The memod accoromg to claim 1, wherein at least one 

„ j *„m„ * u of the upstream side and the downstream side of said each 

as tne second neighboring node. c A . j4 _ c j takt 

. . . °7. 4 °, . ^ - . . . of the second type of nodes is a LAN. 

3. The method according to claun 1, further compnsmg a u ^ met ^ t0 claim 1(Wherein ^ ofthe 

p upstream side and the downstream side of said each of the 

transferring, by said each of the second type of nodes, the ^ ^ of nodcs ^ an ATM or frame relay, 

packet received from an upstream node on the upstream 55 15 The me thod according to claim 1, wherein one of the 

side to a downstream node on the downstream side by upstream side and the downstream side of said each of the 

performing the label switching operation on the packet second type of nodes is an ATM and another of the upstream 

and by updating the information included in the packet side and the downstream side of said each ofthe second type 

based on a default value, when said each of the second of nodes is a frame relay, 

type of nodes has received the second message as the 60 

second neighboring node. * * * * * 
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